home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / standards / CCITT / 1992 / X / x435_4.asc < prev    next >
Encoding:
Text File  |  1993-07-15  |  10.3 KB  |  225 lines
  1.                   The equivalents shown in the following table may also be found to  be
  2.             useful.  Table K.2 relates certain segments of EDIFACT, UNTDI  and  ANSIX12
  3.             in order to show the equivalent terms for each of the three EDI standards. 
  4.                                              TABLE K.2
  5.  
  6.                                 Comparison of terms for EDI Interchange header segments
  7.                   EDIFACT               UNTDI                ANSIX12
  8.                   Interchange Header    Start of Transmission     Interchange 
  9.                Header
  10.                    (UNA and UNB)         (STX)                (ISA)
  11.  
  12.                    Functional Group Header                   -----      
  13.                Functional Group Header
  14.                    (UNG)                                      (GS)
  15.  
  16.                    Message Header        Message Header       Transation Set 
  17.                Header
  18.                    (UNH)                 (MHD)                (ST)
  19.                                               ANNEX L
  20.  
  21.                              Comparison of terms in this Recommendation
  22.                                       and Recommendation F.435
  23.  
  24.                 (This annex does not form an integral part of this Recommendation.)
  25.                   The purpose of this annex is to  facilitate  comparison  between  the
  26.             terminology used in this Recommendation and  that  used  in  Recommendation
  27.             F.435.
  28.                   The  following  table  shows  how  Elements  of  Service  defined  in
  29.             Recommendation  F.435  are  realized  with  protocol   elements   in   this
  30.             Recommendation.  The Elements of Service appear in the order in which  they
  31.             are defined in Annex B of Recommendation F.435.  For  this  Recommendation,
  32.             reference is made to the title of the divisions which define  the  protocol
  33.             elements.
  34.                                              TABLE L.1
  35.  
  36.                                       Comparison of terms in this Recommendation
  37.                                and Recommendation F.435
  38.               Recommendation F.435                    This Recommendation
  39.               Application Security Element            EDI Application Security Element
  40.                Character Set                           EDI Body Part Type
  41.                Cross Reference Information             Cross Referencing Information
  42.                EDI Forwarding                          EDI Forwarding
  43.                EDI Message Type(s)                     EDI Message Type
  44.                EDI Notification Request                EDI Notification Requests
  45.                EDI Standard Indication                 EDI Body Part Type
  46.                EDI-message Identification              EDIM Identifier
  47.               EDIM Responsibility Forwarding Allowed Indication   Responsibility 
  48.             Passing Allowed
  49.                EDIN Receiver                           EDIN Receiver
  50.                Expiry Date/Time Indication             Expiry Time
  51.                Incomplete Copy Indication              Incomplete Copy
  52.                Interchange Header                      Heading Fields from Interchange 
  53.             Header
  54.                Multi-part Body                         EDI Messages
  55.                Non-repudiation of Content Originated   Originate EDIM
  56.                Non-repudiation of Content Received     Originate EDIN and Internal 
  57.             Procedures
  58.                Non-repudiation of Content Received Request   Originate EDIN and Internal 
  59.             Procedures
  60.                Non-repudiation of EDI Notification     Originate EDIN and Internal 
  61.             Procedures
  62.                Non-repudiation of EDI Notification Request   EDI Notification Requests
  63.                Obsoleting Indication                   Obsoleted EDIMs
  64.                Originator Indication                   Originator
  65.                Proof of Content Received               Originate EDIN and Internal 
  66.             Procedures
  67.                Proof of Content Received Request       Originate EDIN and Internal 
  68.             Procedures
  69.                Proof of EDI Notification               Originate EDIN and Internal 
  70.             Procedures
  71.                Proof of EDI Notification Request       EDI Notification Requests
  72.                Recipient Indication                    Recipients
  73.                Related Message(s)                      Related Messages
  74.                Services Indication                     Heading Extensions
  75.                Stored EDI Message Auto-forward         Auto Action Types
  76.                Typed Body                              EDI Messages
  77.                                               ANNEX M
  78.  
  79.                               Realization of an EDIMG User in the Directory
  80.  
  81.                    (This annex does not form an integral part of this Recommendation.)
  82.                       An EDIMG User object class that a Directory administrator can realize
  83.                contains  a  set  of   characteristics   that   define   its   application,
  84.                communication mechanism, depending entity, and naming. The  following  text
  85.                describes how such an EDIMG User object class, for use with EDI  messaging,
  86.                can be realized from the generic EDI  User  object  class  and  suggests  a
  87.                manner in which it can be defined.
  88.                       This need can be rationalized from the following observations:
  89.                       a)  The description of the EDI User object class in Annex J  of  this
  90.                            Recommendation is  that  of  a  generic  EDI  user.  That  is,  a
  91.                            description that does not  presuppose  a  notion  of  a  specific
  92.                            communication mechanism such as MHS. EDI users may desire to  use
  93.                            other communication mechanisms.
  94.                       b)  The definition of the MHS User  object  class  in  Recommendation
  95.                            X.402 is of a generic MHS User. It does not presuppose that a MHS
  96.                            User is associated with any particular kind  of  "named"  entity,
  97.                            such as country, or organization. Also, its definition  does  not
  98.                            limit the MHS User to the Interpersonal Messaging Service.
  99.                       c)  The selected object classes in Recommendation  X.521  define  the
  100.                            characteristics for a set  of  "independent"  entities,  such  as
  101.                            country and organization, and their name  forms.  These  entities
  102.                            are generic  in  the  sense  that  they  are  not  bound  to  any
  103.                            particular kind of user application.
  104.                       d)  Recommendation X.521, Annex B, suggests a  set  of  relationships
  105.                            among these entities. These relationships form the DIT structure,
  106.                            and thus the naming of the entities. As in  point  b  above,  the
  107.                            notion of an application  or  how  applications  are  used  in  a
  108.                            communication mechanism is open ended.
  109.                       e)  The  Directory  recommendations  do  not  prescribe  a  "binding"
  110.                            mechanism that will allow the formation of composite objects from
  111.                            generic objects. 
  112.                       To realize a Directory entry for an EDIMG user requires  that  a  new
  113.                unregistered object class  be  defined.  This  new  object  class  forms  a
  114.                composite of the characteristics from each desired  generic  object  class,
  115.                for example, by combining the EDI User object class  and  MHS  User  object
  116.                class into a new unregistered object class. In ASN.1 this may be  expressed
  117.                as:
  118.                       edimg-user OBJECT CLASS  ::=  SUBCLASS OF edi-user, mhs-user
  119.                       NOTE -  An  Unregistered  Object  Class  is  discussed  in  9.4.1  of
  120.                Recommendation X.501,  as  an  object  class  without  an  assigned  object
  121.                identifier. It is intended for local use as a means of conveniently  adding
  122.                new attribute types to a pre-defined superclass.
  123.                       In this example, the edimg-user is a type identifier specified by the
  124.                defining Directory administration.  Additionally,  the  administration  may
  125.                include private attributes by adding  the  MUST  CONTAIN  and  MAY  CONTAIN
  126.                statements to the unregistered object class definition.
  127.                       In addition to the definition of the content of Directory entries  by
  128.                use of the object class notation, a naming policy for these entires is also
  129.                required.  For example, using the approach of  Annex  B  of  Recommendation
  130.                X.521 it may be specified that for entries of the EDI  User  object  class,
  131.                the EDI Name attribute is used for naming; entries of this object class may
  132.                be immediately subordinate to entries of for example,  Organization  object
  133.                class or Organizational Unit object class.
  134.                       To provide an alternative  name  for  an  EDIMG  user  requires  that
  135.                another unregistered object class be defined. This new object class forms a
  136.                composite of the characteristics  from  the  alias  object  class  and  the
  137.                desired EDI user naming attribute. In ASN.1, this may be expressed as:
  138.                       edimg-user-alias OBJECT CLASS  ::=  SUBCLASS OF alias  MUST CONTAIN {edi-name}
  139.                       the 
  140.                the naming policy of the unregistered EDIMG User object class.
  141.             Index     
  142.                   This annex indexes  this  Recommendation.  It  gives  the
  143.             number(s) of the page(s) on which each item in each of several
  144.             categories is  defined.  Its  coverage  of  each  category  is
  145.             exhaustive.
  146.             This annex indexes items (if any) in the following categories:
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224. CCITT Draft Rec. X.435     page1
  225.